Shell 


Whenever you login to a Linux system you are placed in a shell program. The shell's prompt is 
usually visible at the cursor's position on your screen. To get your work done, you enter 
commands at this prompt. 


The shell is a command interpreter; it takes each command and passes it to the operating 


system kernel to be acted upon. It then displays the results of this operation on your screen. 


Several shells are usually available on any UNIX system, each with its own strengths and 


weaknesses. 


Different users may use different shells. Initially, your system administrator will supply a 
default shell, which can be overridden or changed. The most commonly available shells are: 
Bourne shell (sh) 

e C shell (csh) 

e Korn shell (ksh) 

e TC Shell (tcsh) 

e Bourne Again Shell (bash) 


Each shell also includes its own programming language. Command files, called "shell scripts" 
are used to accomplish a series of tasks. 


Shell Script Execution 
Once a shell script is created, there are several ways to execute it. However, before any Korn 
shell script be can executed, it must be assigned the proper permissions. The chmod command 


changes permissions on individual files, in this case giving execute permission to the simple file: 


$ chmod +x simple 


After that, you can execute the script by specifying the filename as an argument to the bash 


command: 


$ bash simple 


You can also execute scripts by just typing its name alone. However, for that method to work, 
the directory containing the script must be defined in your PATH variable. When looking at 
your .profile earlier in the course, you may have noticed that the PATH=$PATH:$}HOME 
definition was already in place. This enables you to run scripts located in your home directory 
(SHOME) without using the ksh command. For instance, because of that pre-defined PATH 


variable, the simple script can be run from the command line like this: 


$ simple 


(For the purposes of this course, we'll simplify things by running all scripts by their script name 


only, not as an argument to the ksh command.) 


You can also invoke the script from your current shell by opening a background subprocess - or 
subshell - where the actual command processing will occur. You won't see it running, but it will 
free up your existing shell so you can continue working. This is really only necessary when 
running long, processing-intensive scripts that would otherwise take over your current shell 


until they complete. 


To run the script you created in the background, invoke it this way: 


$ simple & 


When the script completes, you'll see output similar to this in the current shell: 


[1] - Done (127) simple 


It is important to understand that Korn shell scripts run in a somewhat different way than they 
would in other shells. Specifically, variables defined in the Korn shell aren't understood outside 
of the defining - or parent - shell. They must be explicitly exported from the parent shell to work 
in a subsequent script or subshell. If you use the export or typeset -x commands to make the 
variable known outside the parent shell, any subshell will automatically inherit the values you 
defined for the parent shell. 


For example, here's a script named lookmeup that does nothing more than print a line to 
standard output using the myaddress (defined as 123 Anystreet USA) variable: 


$ cat lookmeup 
print "I live at $myaddress" 


If you open anew shell (using the ksh command) from the parent shell and run the script, you 
see that myaddress is undefined: 


$ ksh 
$ lookmeup 


I live at 


However, if you export myaddress from the parent shell: 


$ exit 
$ export myaddress 


and then open a new shell and run the lookmeup script again, the variable is now defined: 
$ ksh 
$ lookmeup 


I live at 123 Anystreet USA 


To illustrate further how the parent shell takes processing precedence, let's change the value of 
myaddress in the subshell: 


$ myaddress='Houston, Texas' 


$ print $myaddress 
Houston, Texas 


Now, if you exit the new shell and go back to the parent shell and type the same command: 
$ exit 


$ print $myaddress 
123 Anystreet USA 


you see that the original value in the parent shell was not affected by what you did in the 
subshell. 


A way to export variables automatically is to use the set -o allexport command. This command 
cannot export variables to the parent shell from a subshell, but can export variables created in 
the parent shell to all subshells created after the command is run. Likewise, it can automatically 
export variables created in subshells to new subshells created after running the command. set -o 


allexport is a handy command to place in your .kshre file. 


Shell Scripts - An Illustrated View 
At the risk of sounding redundant, let's recap: shell scripts are simply files containing a list of 
commands to be executed in sequence. Now let's go a bit further and look at a shell script, line- 


by-line. 


Any Korn shell script should contain this line at the very beginning: 


#!/usr/bin/ksh 


As you probably already know, the # sign marks anything that follows it on the line as a 
comment - anything coming after it won't be interpreted or processed as part of the script. But, 
when the # character is followed by a! (commonly called "bang"), the meaning changes. The line 
above specifies that the Korn shell will be (or should be) executing the script. If nothing is 
specified, the system will attempt to execute the script using whatever its default shell type is, 
not necessarily a Korn shell. Since the Korn shell supports some commands that other shells do 
not, this can sometimes cause a problem. To be valid, this line must be on the very first line of 
the script. 


Shell scripts are often used to automate day-to-day tasks. For example, a system administrator 
might use the following script, named diskuse here, to keep track of disk space usage: 


#!/usr/bin/ksh 

# diskuse 

# Shows disk usage in blocks for /home 
cd /var/log 

cp disk.log disk.log.0 

cd /home 


du -sk * > /var/log/disk.log 
cat /var/log/disk.log 


Shown again - but this time with annotation - the script's processing steps are clear: 


#!/usr/bin/ksh 
# SCRIPT NAME: diskuse 
# SCRIPT PURPOSE: Shows disk usage in blocks for /home 


# change to the directory where disk.log resides 
cd /var/log 


# make a copy of disk.log 
cp disk.log disk.log.0 


# change to the target directory 
cd /home 


# run the du -sk * command on all files 
# in /home and redirect the output 

# to /var/log/disk.log 

du -sk * > /var/log/disk.log 


# display the output of the du -sk * 
# command to standard output 


cat /var/log/disk.log 
It's not a good idea to hard-code pathnames into your scripts like we did in the previous 
example. We specified /var/log as the target directory several times, but what if the location of 
the files changed? In a short script like this one, the impact is not great. However, some scripts 
can be hundreds of lines long, creating a maintenance headache if files are moved. A way 
around this is to create a variable to take the place of the full pathname, such as: 
LOGDIR=/var/log 


The fourth line of the script would change from: 


cp disk.log disk.log.0 


to: 


cp ${LOGDIR}/disk.log ${LOGDIR}/disk.log.0 


Then, if the locations of disk.log changes in the future, you would only have to change the 
variable definition to update the script. Also note that since you are defining the pathname with 
the LOGDIR variable, the cd /var/log line in the script is unnecessary. Likewise, the du -sk * > 
/var/log/disk.log and cat /var/log/disk.log lines can substitute ${LOGDIR} for /var/log. 


